Data backup fulfills three important goals: protection, preservation and compliance. Data backup is a protective measure because it ensures against data loss. It is a preservative measure because it enables version tracking. It is a compliance measure because data backup and retention may be required by law. In order to fulfill these three goals, data backup must be seamless, up to date and fully recoverable. If backed up data cannot be fully recovered and restored to an accessible state at any selected point in time, then the goals of data backup are not met.
Organizations that generate and access large amounts of data typically use numerous different information technology (IT) assets connected over a network. IT assets include the hardware and software used to create, store and access the data. In most organizations, one department is responsible for acquiring IT assets (purchasing) while another department is responsible for maintaining these assets (IT). As an organization grows, it acquires more IT assets and generates more data. It is the IT department's responsibility to ensure that the IT assets and the data associated with these assets perform as expected. Additionally, the IT department must make sure that the data is periodically backed up. The IT department will typically employ Backup, Recovery and Archiving (BURA) applications to manage data backup. In order to ensure that all data is properly backed up and archived, each IT asset must be configured to work with the BURA application. Maintaining the hardware and software configurations for newly acquired IT assets is usually performed manually on a computer by computer basis by IT personnel.
In large organizations, there is often a lack of communication between the purchasing department and the IT department. As a result, the purchasing department may not notify the IT department when new IT assets are added to the network. The purchasing department may acquire a number of computer workstations and attach them to the network, allowing these workstations to generate and access network data without ensuring that these workstations have been properly configured for backup. Additionally, individual users may purchase and install their own computers or other IT assets without notifying the IT department. A user may also independently install software on a company computer without consulting the IT department, which may unknowingly affect the computer's configuration. As a result, data from these unknown or altered IT assets may not be adequately backed up or protected by the BURA application. While in most cases, these IT assets may operate for extended time periods without issue, in the event of a disaster, the data stored by these assets may be irrevocably lost.
As noted previously, once an IT asset has been added or altered, an IT person must manually configure the IT asset to ensure that it communicates with the BURA application for backup purposes. Manual configuration may involve identifying the type of operating system on the IT asset, the amount of storage space on the IT asset, and the hardware profile of the IT asset. Configuration may also require the installation of drivers, APIs or other software agents that enable communication with the BURA application. Manual configuration is a tedious and time-consuming process that reduces the availability of IT personnel for other more important tasks. In event that an IT asset loses the ability to communicate with the BURA application due to user interference or the unauthorized installation of software, it is often difficult for the IT person to discover what changes have been made to the IT asset. Figuring out how an IT asset has changed is also extremely time-consuming and an inefficient use of IT personnel.
In addition to the above, other issues may arise when data created or accessed on one computer is stored on another computer or server. As a result, other computers on the network may also manipulate the same data files. In order to be effective, the BURA application must be able to access all forms and locations of these stored data files. Present BURA applications typically create mirrored backups of all stored data files by periodically copying, compressing and archiving them onto media for permanent storage. While this meets most compliance policies, it does not guarantee that these archived data files will be accessible if recovered. Storage of data alone is not enough to ensure that in the event of a disaster, a network and its IT assets can be re-built and operational in the exact same state as prior to disaster. This is because simply copying or moving data into storage does not account for changes in the software that is used to access that data. Software upgrades can sometimes prevent users from accessing older data files created or accessed using previous software versions.
Hardware upgrades may also hinder access to archived data. IT asset hardware and operating system changes can affect the data files associated with the hardware in subtle ways. Present BURA applications typically backup and archive the data stored on IT assets, but ignore the configurations or precise setups of these IT assets. As a result, while the data may be preserved, the relationships between the data and the hardware may not be protected. Data stored without considering the hardware and software configurations associated with the data may render those stored files inaccessible or inoperable, even if the files are successfully recovered.
Another issue affecting data backup and recovery involves the timing of backed up IT assets. A backup session may be scheduled to occur at specific time intervals, but the time intervals for each IT asset or server on the network may not be the same. For example, an email server may be backed up weekly, but a less commonly accessed storage server may only be backed up monthly. Changes in hardware and software can occur between these different backup sessions, in addition to changes in the data that may be accessed on both servers. As a result, during recovery, if the different servers are restored using backups created at different times, the data on the restored servers may not be properly synchronized. As a result, data may be lost or inaccessible. Present methods may therefore not be fully effective at meeting the goals of data backup. Access to archived data files may be dependent upon recognizing the proper software and/or hardware configurations used to create those files.
What is therefore needed is a way to enable intelligent backup and recovery. The hardware or software application responsible for backup and recovery needs a way to keep track of all of the configurations and relationships between all of the data, hardware and software that are backed up. The application also needs a way to account for changes to the network, including software or hardware upgrades, installation or removal of software and hardware, and changes to the data. The application further needs a way to identify when new IT assets have been added to the network, and to ensure that the IT assets are properly configured to work with the application, and that data stored on these IT assets are adequately protected by the application.